Here are some of the connectors you should have on your system:
</p>
<ul>
<li>
<em>Capture card coaxial input</em>: A round, threaded connector with a small hole in the middle that accepts modulated signals with audio (multiple channels).
</li>
<li>
<em>Capture card composite input</em>: A smooth, non-threaded (RCA) connector with a large hole in the middle. This connector accepts a single video input
without audio. The composite video cable, or the composite video portion of an octopus cable, usually has a yellow connector.
</li>
<li>
<em>Capture card S-Video input</em>: A rounded socket with four pin holes and a small rectangular slot (DIN-4). This connector accepts a single video input
without audio, but with brightness and color information separated. The result is higher video quality than composite input. S-Video cables usually have a black
connector.
</li>
<li>
<em>Capture card line input</em>: A mini-mono or mini-stereo socket about 1/8" in size, this is the audio input for the composite video and S-Video inputs.
</li>
<li>
<em>Capture card line output</em>: Also a mini-phone socket about 1/8" in size, this is the audio output from the capture card.
</li>
<li>
<em>Sound card line input</em>: A third mini-phone socket, this is the input to the sound card for recording. On sound cards with color-coded inputs, this should
be blue in color.
</li>
</ul>
<p>
If you have an all-in-one style capture device that does both video and audio, especially one over USB, then hooking it up
is a no-brainer: just connect everything to the capture device. You don't have a choice anyway. If you have a "TV tuner" style
device, though, then some of the capture work is also being done by the sound card, and you have to hook up a couple of cables
to get everything working.
</p>
<h2>Capturing from cable (coaxial input)</h2>
<p>
In this scenario, you have a TV tuner type capture card and want to capture from a TV channel.
</p>
<ul>
<li>Connect the round coaxial cable to the capture card.</li>
<li>Connect the line-out from the capture card to the sound card line-in.</li>
</ul>
<p>
The TV tuner card accepts the cable input, selects and decodes the desired channel, captures the video, and splits off
the audio for your sound card to capture.
</p>
<h2>Capturing from audio/video outputs</h2>
<p>
In this scenario, you have a TV tuner type capture card and want to capture from another device that has separate audio
and video outputs, such as a VCR or video game console.
</p>
<ul>
<li>Connect the composite video or S-Video output to the same video input on the capture card.</li>
<li>Connect the audio output from the output device to the capture card line-in.</li>
<li>Connect the line-out from the capture card to the sound card line-in.</li>
</ul>
<p>
The problem you will often encounter here is that the output device will have a pair of round RCA connectors, one for
each of the left/right stereo channels (red and white), while the capture and sound cards will have 1/8" mini-stereo inputs. A cable with
a male 1/8" on one end with stereo RCA male connectors on the other end, along with a pair of RCA female-female adaptors,
will help you hook everything up here.
</p>
<p>
This assumes that you have a capture card that has integrated audio capture. If your capture card simply passes through
the audio, it's better just to connect the audio output directly to the sound card:
</p>
<ul>
<li>Connect the composite video or S-Video output to the same video input on the capture card.</li>
<li>Connect the audio output from the output device directly to the sound card line-in.</li>
</ul>
<p>
This shortens the audio path for better quality, and you won't have to worry about whether the capture card's audio
mixer is set to the right level or the correct input.
Capturing live video is a real-time operation and places high demands on your system. Here are some steps you
can take to improve video capture performance.
</p>
<h2>
Shut down background tasks and applications
</h2>
<p>
Interruptions by background programs can interfere with video
capture and cause dropped frames. Applications you should watch out for, and temporarily disable, include:
</p>
<ul>
<li>virus scanners</li>
<li>disk defragmenters</li>
<li>search indexers, especially the Microsoft Indexing Service (formerly Microsoft Office Fast Find Indexer)</li>
<li>task schedulers</li>
<li>on-screen tickers and status readers — particularly anything that flashes or scrolls on-screen</li>
</ul>
<p>
CPU usage is a problem here, but competition for the hard disk is usually a much worse problem: any attempts
to access the disk by another application will cause the disk to seek back and forth, which seriously cuts
available write bandwidth.
</p>
<p>
Absolutely avoid using the CD-ROM drive during video capture, as the access traffic during the spin-up of the
CD-ROM drive can cause the hard drive to go off-line for more than a second.
</p>
<p>
It is not recommended to use other applications during video capture. Even if the other applications are light
in disk and CPU usage, they may cause momentary hiccups that result in dropped frames or timing anomalies during
the capture. The less that is going on in the system, the more accurate VirtualDub's timing statistics are and
the better it can keep audio and video streams in synchronization.
</p>
<lina:note>
When in capture mode, VirtualDub temporarily sets its process priority to High and disables both the screensaver
and power saving mode on the display device. It isn't necessary to change these manually.
</lina:note>
<h2>
Keep the disk clean
</h2>
<p>
Hard drives reach peak write performance when writing sequentially on disk — the more they have to seek
around to different regions, the lower the available bandwidth. When files are scattered throughout a disk, free
space is broken into a lot of small chunks, which is called <em>fragmentation</em>. This means that it is important to have large
areas of contiguous free space on a drive. Here are some tips to improve disk write performance:
</p>
<ul>
<li>
Run Disk Defragmenter and check that free space is not overly fragmented on the target drive. The fragmentation
of existing files doesn't matter, just the free space. It's OK if the free space is split into a few dozen
chunks, as a seek every minute isn't a problem. If it's really swiss-cheesed, though, consider defragmenting.
</li>
<li>
Have extra free space on the drive. VirtualDub allocates large blocks of space a time to give Windows a chance
to find clear areas on the drive; however, this becomes more difficult as the drive gets full and Windows scavenges
for the last free space on the disk. Fragmentation becomes much worse once you start filling the last 5-10% of a drive.
</li>
<li>
Use a different partition or disk than the one that holds Windows system files, as that partition typically
has a large number of small, volatile files and fragments very quickly.
</li>
</ul>
<h2>
Use appropriate video compression and video formats
</h2>
<p>
Uncompressed video capture dumps a <em>lot</em> of data onto the disk — 720x480 in 16-bit YUY2 at 29.97 fps produces
approximately 20 megabytes per second. Modern computers have much more CPU power and thus you can reduce the strain on
the disk by storing the video in a more efficient format.
</p>
<p>
Start by choosing an efficient raw video format for your capture device to produce:
</p>
<ul>
<li><em>32-bit RGB</em>: Avoid this format, as it wastes 33% of the space used.</li>
<li><em>24-bit RGB</em>: This is the baseline, most compatible format. Start here.</li>
<li><em>15/16-bit RGB</em>: Avoid, as it introduces serious banding (quantization) artifacts.</li>
<li><em>16-bit YCbCr (UYVY or YUY2)</em>: Try this format. It is closer to the format produced internally by most hardware
video decoders and used internally by many video codecs, but it is 33% smaller than 24-bit RGB. Using this format will
often significantly improve performance.</li>
</ul>
<p>
Apply video compression on top of this to further reduce data bandwidth. Because the raw video capture will likely
need some post-editing to be useful, avoid formats that overly degrade video or are difficult to edit.
</p>
<ul>
<li>
The <em>Huffyuv</em> video codec by Ben Rudiak-Gould is an excellent capture codec to use, as it is lossless, typically
achieves around a 2:1 compression ratio, and can work directly with YCbCr video. It is very fast and should work in
real-time on a 500MHz or faster CPU.
</li>
<li>
<em>Motion-JPEG (MJPEG)</em> codecs are also an excellent choice. They are lossy and thus will reduce video quality
very slightly, but the compression ratio is significantly better than lossless codecs like Huffyuv, at least 4:1 with
little or no perceptible quality loss. The Motion JPEG format
is also field-savvy and will store interlaced video without screwing up the fields.
</li>
<li>
<em>Digital Video (DV)</em> is another format to consider. Like Motion JPEG, DV is also a slightly-lossy format that is
friendly to interlaced video. It does take a bit more CPU to compress and decompress, however. Also, unlike Motion JPEG,
DV is always constant in data rate — 3.6MB/sec — so it is easy to predict how much disk space is required for
a given amount of time.
</li>
<li>
<em>MPEG-4</em> and other high-compression video formats should be avoided, as they require significant
CPU power to compress and may not be able to keep up with the incoming video at adequate quality. Also, their extremely
long delta frame chains can make the resulting video difficult or impossible to edit.
</li>
</ul>
<p>
Note that if you have a capture device that has hardware video compression, your options here are likely very limited.
In that case, browse the capture driver's configuration dialogs, usually <em>Video > Video Source</em> or <em>Video > Capture Filter</em>,
and select a format with relatively light compression.
</p>
<h2>
Disable audio compression
</h2>
Uncompressed audio requires much less bandwidth than uncompressed video and reasonable audio compression usually
requires a lot of CPU power. This is particularly true of modern audio compression formats such as MPEG audio layer III (MP3).
It is highly recommended that you <em>not</em> use audio compression during video capture, as it can consume a lot of CPU
and make video capturing less reliable.
</lina:create>
<lina:create file="c-infopanel.html" title="Capture: Information panel">
<blockquote>
<lina:image src="pics/c-infopanel.png"/>
</blockquote>
<p>
The information panel shows current disk, video, and audio status during a video capture. It is toggled through the <i>Option > Show information panel</i>
menu command. Not all entries are always shown; the subset that is displayed can be changed in Preferences.
</p>
<dl>
<dt>Frames captured</dt>
<dd>The total number of video frames captured.</dd>
<dt>Total time</dt>
<dd>The amount of time the capture has been running, in days:hours:minutes:seconds.</dd>
<dt>Time left</dt>
<dd>The estimated amount of time the capture can continue, based on available disk space, video frame rate, and
current compression ratios.</dd>
<dt>Total file size</dt>
<dd>The total amount of data written to disk in the current capture session.</dd>
<dt>Disk space free</dt>
<dd>How much disk space is left on the capture drive(s).</dd>
<dt>CPU usage</dt>
<dd>Estimated CPU utilization during the video capture. This includes CPU usage by processes other than VirtualDub.
<lina:note>
On a system with multiple logical CPUs (SMP, dual core, or hyperthreading), this value may rise above 100%,
up to 100% times the number of CPUs. Video capture is mostly single-threaded, so approaching 100% in these
situations may still indicate CPU overload.
</lina:note>
</dd>
<dt>Spill status</dt>
<dd>
Current status of a multi-segment capture operation. Normally this will indicate which segment number
is currently being written; it will also indicate when the capture engine is in the process of spilling
over from one segment to the next. If the spill takes a long time or never completes, this can prevent
VirtualDub from switching files and may be indicative of a bad audio/video timing problem.
</dd>
<dt>Video: Size</dt>
<dd>Total amount of video data written to disk.</dd>
<dt>Video: Average rate</dt>
<dd>The overall rate at which video frames are arriving from the video capture device. The more this
diverges from nominal, the more likely sync and frame drop problems are to appear.</dd>
<dt>Video: Data rate</dt>
<dd>The overall rate at which video data is being written to disk, in bytes/kilobytes/megabytes per second.
When video compression is in use, this statistic refers to compressed video data.
</dd>
<dt>Video: Compression</dt>
<dd>The overall video compression ratio. Ratios greater than 1.0:1 indicate shrinkage in video size, whereas
less than 1.0:1 means enlargement (i.e. the "compression" is making the video bigger). Lossless algorithms
typically range from 1:1 to 3:1, whereas lossy compression can go much higher.
</dd>
<dt>Video: Avg frame size</dt>
<dd>The average size, in bytes, of each video frame written to disk. When video compression is in use, this
statistic refers to compressed video frames.
</dd>
<dt>Video: Frames dropped</dt>
<dd>This refers to the number of aberrations in the video stream which caused VirtualDub to drop a frame
in the video stream due to them being crowded too close together (too fast). Fewer is better, although
it is normal for frame drops to occur where there are disruptions in the video stream, such as the
start of a new recording on a tape.
</dd>
<dt>Video: Frames inserted</dt>
<dd>This refers to the number of aberrations in the video stream which caused VirtualDub to insert a placeholder frame
into the video stream due to there being too few frames in that area (too slow). Fewer is better, although
it is normal for frame inserts to occur where there are disruptions in the video stream, such as the
start of a new recording on a tape.
</dd>
<dt>Video: Resampling factor</dt>
<dd>When video timing correction is enabled, this indicates the factor by which "video time" is being accelerated
or slowed to match the expected output rate. This is only active if video timing correction is enabled. Unlike
audio resampling, video resampling only affects the assignment of frame numbers to incoming video frames; a
number other than 1x does not mean that video frames are being interpolated.
</dd>
<dt>Audio: Size</dt>
<dd>Total amount of audio data written to disk.</dd>
<dt>Audio: Average rate</dt>
<dd>
The average rate of the raw PCM data in the audio stream, relative to real time. This is the estimated actual
frequency of the incoming audio data. Small discrepancies in this value from expected are normal, as all clocks
have some error; however, large discrepancies in this value from the specified sampling rate may
indicate that the sound card has an audio clock with poor accuracy. Audio resampling can be used to stretch
the audio to compensate.
</dd>
<dt>Audio: Relative rate</dt>
<dd>The average rate of the raw PCM data in the audio stream, relative to the <i>corrected</i> video stream.
This is thus the frequency of the audio if the video stream were perfectly timed, as it is assumed in
the on-disk video. Discrepancies between this value and the ideal frequency indicate overall sync error.
Small errors are expected due to measurement issues.
</dd>
<dt>Audio: Data rate</dt>
<dd>Average bandwidth of audio data written to disk. When audio compression is active, this refers to
the compressed result.
</dd>
<dt>Audio: Compression</dt>
<dd>The overall audio compression ratio; larger ratios mean smaller audio on disk.
</dd>
<dt>Audio: Resample</dt>
<dd>Stretch factor applied to the audio stream, in semitones, in order to correct for speed errors relative to the video stream. This is only active if the timing setting
is "sync audio to video." A semitone is a step between minor notes on the musical scale, such as between the notes C and C#; a factor
of +/-12.000 is a full octave (half or double speed).
Positive values indicate the audio is being sped up (higher pitch), negative values indicate slowing (lower pitch), and zero means
no change to the audio speed.
<p>
This value is an instantaneous measurement, not an average, so a varying adjustment means varying speeds in
the written audio track.
</p>
<p>
An adjustment within about 0.030 semitones is not usually noticeable, and slow, gradual drifts or oscillations in this value
are normal. However, factors above +/-0.100 semitones and rapid changes in this value indicate warbling in
the resampler's output, which may indicate timing problems.
</p>
</dd>
<dt>Sync: Video timing adjust</dt>
<dd>Amount of adjustment, in milliseconds, applied to the video stream caused by detected differences from audio timing. This
is only pertinent if the timing setting is "sync video to audio." Positive values mean the video stream
is being sped up; negative values mean it is being slowed down. It is normal for this value to increment or decrement
occasionally over the course of a video capture session.
</dd>
<dt>Sync: Relative latency</dt>
<dd>Estimated difference in arrival time, in milliseconds, between the audio and video streams. This is the difference between when VirtualDub sees
a video frame and the audio that corresponds to that frame, not necessarily a sync error in the output. Positive values
indicate the audio is arriving later, whereas negative values indicate it is arriving earlier. This value will typically be
in to 10-100ms range for "TV tuner" style devices and possibly as high as +/-300ms for devices with integrated compression.
<p>
An abnormally large value here, particularly in the range of seconds or more, likely indicates a timing problem.
</p>
</dd>
<dt>Sync: Current error</dt>
<dd>Estimated sync error between the audio and video streams; zero means that the audio and video streams are in sync. This is only
calculated if the sync mode is "sync audio to video." The audio resync controller continually adjusts the audio resampling rate
in an attempt to drive this error as close to zero as possible.
